值班工程師請 Agent 查服務延遲，通常會同意它讀取相關 Log 和 Metrics，卻不會因此准許它查遍所有團隊的資料。同一個查詢工具，能不能執行還取決於目標和這次交辦的範圍。

Day 3 的 Google ADK Lab 已用工具清單擋下 delete_demo_database，這個安全工具只模擬刪除、不碰資料庫。當時看到 POLICY_DENIED，我以為執行前授權已經有了不錯的起點。回頭看 callback，我才發現授權判斷只收到 Tool name：

decision = policy.authorize(tool.name)

像 delete_demo_database 這種名稱，本來就很適合用 allowlist 拒絕。可是真正難處理的，通常不是一看就危險的 Tool，而是 query_metrics 這類每天都會使用的正常功能。同一個 Tool，有時應該放行，有時卻不該碰到目標資源。只看名稱的 policy 分不出來。

同一個 query_metrics，答案可以完全不同

假設值班工程師正在調查 payments-api 的延遲。Agent 呼叫：

query_metrics(service="payments-api")

這筆請求符合原本的調查目的，應該放行。另一條路徑仍由同一位工程師發起，但 Agent 讀到的外部 Log 夾帶指令，把查詢目標帶往另一個團隊的 production service：

query_metrics(service="another-team-api")

第二筆不是工程師原本要查的範圍，也沒有額外核准。問題是目前的 policy 對兩筆請求看到的內容完全相同：

authorize("query_metrics") → ALLOW

Lab 裡的 query_metrics 只會回傳固定的合成指標，不會真的連到 Grafana。這裡使用它現有的 service argument 做 threat model，目的是把授權缺口攤開來看，而不是宣稱第二筆查詢真的碰過 production。

Allowlist 其實只看見一個字串

ADK 的 callback 不只拿得到 Tool name，也拿得到 arguments。現有程式甚至把 args 寫進 policy.decision 事件：

decision = policy.authorize(tool.name)

store.record(
    "policy.decision",
    tool_name=tool.name,
    tool_arguments=args,
    decision="ALLOW" if decision.allowed else "DENY",
)

這段程式很容易讓人誤會成「授權資料都有記錄」。但事件裡有 tool_arguments，不等於 policy 做決定時看過它。Session 裡的 synthetic-user-sre-oncaller 和 Agent 名稱 sre_investigation_agent 也是同樣情況。它們有值，卻沒有進入 authorize()。

更麻煩的是，session label 沒有 issuer 或 credential 可以證明它是哪位使用者，Agent 名稱也只是受控 metadata。這個合成 Tool 沒有送出下游請求，所以目前還談不上用哪枚下游憑證。資料存在、來源可信、policy 看得到，這三件事不能混在一起。

把現有 callback 畫成資料流，缺口更容易看見：左邊雖然記下了參數和 session label，真正送進 authorize() 的只有 Tool name。下方的 Caller 驗證與目標解析是下一步需要補上的路徑，不是這份 Lab 已經做到的功能。

這種權限錯置早在 Agent 出現前就存在

1988 年，Norm Hardy 在〈The Confused Deputy〉描述了一個 Compiler。Compiler 必須用自己的權限寫入計費檔案，同時也允許使用者指定編譯輸出的檔名。當使用者把輸出位置指向計費檔案時，真正覆寫檔案的不是使用者，而是握有合法權限的 Compiler。

這類問題後來被稱為 Confused Deputy。Deputy 本身有權執行動作，卻把自己的權限用在呼叫者不該要求的目標上。

換回 Agent 場景，Agent runtime 就可能是那個 Deputy。它握有查詢 production metrics 的 credential，query_metrics 也在 allowlist 裡。外部 Log 只要成功改變查詢目標，runtime 就可能拿自己的真實權限完成一筆偏離原始任務的操作。

Prompt Injection 是造成這種偏離的一種方式，但不是 Confused Deputy 的定義。即使系統裡沒有 LLM，只要低信任輸入能控制目標，而受信任程式又拿自己的權限照做，同樣的問題就會出現。

授權至少要回答三件事

Tool allowlist 已經提供 action。要分辨前面兩筆 query_metrics，policy 還得知道經過驗證的呼叫者，以及這次真正要碰的目標資源：

authorize(
  principal = verified caller,
  action    = query_metrics,
  resource  = service/payments-api,
  scope     = this incident
)

principal 不一定是坐在瀏覽器前的人。排程任務可能使用 service principal，互動式 Agent 則可能需要保留 Human delegation。無論是哪一條路徑，policy 都不能用 Agent 名稱假裝成 Human，也不能用 requested argument 直接當成已驗證的 resource。

scope 則用來回答「這次受託範圍到哪裡」。值班工程師可以查 production metrics，不表示 Agent 得到一張可任意查詢所有服務的通行證。實際要保存哪些欄位，會依 Tool 風險與資源類型而變，但決策至少要能把呼叫者、動作與目標對起來。

有資料、可信、Policy 可見是三回事

把 Day 3 的實際事件攤開後，目前能確認的是：

完整版本放在 Agent Delegation Decision Table。這份表把「欄位有值」「由誰證明」和「policy 是否真的使用」分開，適合拿去檢查其他 Agent action。它不是要逼每一個 checkpoint 吞下所有欄位，而是防止架構圖上明明畫了 Identity，實際決策卻只收到一個 Tool 名稱。

Policy 做決定時要看當下可驗證的呼叫者、動作與目標。Audit 則可以保存較完整的責任鏈，讓事後查出誰提出目的、哪個 Agent 做了選擇。如果真的呼叫了下游服務，再記錄那一跳用的憑證與請求結果。兩者使用的資料有交集，但用途不同。

下一步，把缺口放回完整治理地圖

Day 4 先把「合法 Tool 為什麼仍可能用錯權限」說清楚。現在已經知道 policy 缺少 verified caller、target resource 與 delegation scope，但這還只是整條 Agent action path 的一部分。

下一篇會把同一筆動作從 Human、Agent 一路追到 Tool。等它真的連上外部服務，再檢查下游 caller。除了眼前缺少的身分與資源授權，執行版本、拒絕位置和事後紀錄也會影響事故能否查清楚。先把問題擺在同一張圖上，後面談產品時才不會誤以為買到某項功能，就等於整條路徑都有人負責。